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AN  INTEGRATED  DATABASE  ARCHITECTURE  FOR  SYSTEMS 
STUDIES  IN  UNDERWATER  ACOUSTICS 

D.J.  Kewley,  P.S.  Keays  and  AS.  Burgess 


SUMMARY  (U) 

An  overview  of  the  development  of  an  Underwater  Acoustics  Database  for  use  in 
systems  studies  applications  is  given.  The  database  is  managed  by  the  locally 
developed  Graphical  Database  Management  System  (GDBMS).  This  general 
purpose  database  management  system  has  been  designed  to  meet  the  needs  of 
scientists  working  with  oceanographic  data.  The  important  features  of  the  system 
include  the  flexibility  to  handle  data  in  a  variety  of  formats,  minimum  redundancy 
storage  space,  automatic  scaling  and  presentation  of  data  from  dissimilar  sources 
(in  user  specified  formats)  upon  retrieval,  and  the  simple  keyword  driven 
operation  designed  for  non-programmer  users.  Unusual  features  include  the 
provision  for  graphical  input  and  output  of  multi-dimensional  data  and  interfaces 
to  other  user  computer  programs.  Examples  of  several  data  tables  or  'relations' 
using  the  GDBMS  methods  are  given.  Reference  to  how  the  database  can  be 
accessed  by  the  Passive  Array  Sonar  Prediction  (P  ASP)  code  which  provides  signal 
excess  predictions  is  also  included. 
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1.  INTRODUCTION 


1 . 1  Background 

Maritime  Systems  Division  of  Weapons  Systems  Research  Laboratory  is 
responsible  for  research  and  development  activities  to  improve  passive 
sonar  systems.  This  work  includes  assessment  of  the  performance  of  present 
and  future  sonobuoys,  and  research  and  development  activities  on  towed 
hydrophone  arrays  for  naval  vessels.  These  studies  require  both 
theoretical  and  experimental  work  to  be  undertaken  to  investigate  the 
current  performance  of  existing  systems  and  to  assess  the  potential  of 
either  modifications  to  current  systems  or  entirely  new  concepts. 
Eventually  both  theoretical  and  experimental  results  of  individual  aspects 
of  these  investigations  have  to  be  reconciled  to  provide  total  systems 
performance  evaluations. 

The  representations  of  data  associated  with  separate  aspects  of  a  total 
system  frequently  have  a  variety  of  forms  and  different  dimensionalities. 
For  example,  propagation  loss  for  a  number  of  different  scenarios  may  be 
tabular  or  plotted  against  range  while  the  detection  threshold  may  be  a 
single  number. 

A  database  approach  is  considered  the  best  way  of  managing  the  large 
quantity  of  data  required  for  systems  studies  applications  and  for  ensuring 
the  accessibility  of  data  to  a  number  of  users  who  may  not  necessarily  be 
programming  specialists.  The  term  database  is  used  here  in  the  sense  of  a 
structured  collection  of  data  of  some  particular  type  and  which  is  managed 
by  a  software  system  referred  to  as  the  Database  Management  System  (DBMS). 
A  database  comprises  a  number  of  'relations'  which  are  2-dimensional  data 
tables. 

1.2  The  Graphical  Database  Management  System  (GDBMS) 

Commercial  database  management  systems  (DBMS)  were  examined  and  found  to  be 
lacking  in  fundamental  ways,  so  an  appropriate  Graphical  Database 
Management  System  (GDBMS)  was  developed  by  one  of  the  authors  (Keays)  to 
serve  Maritime  Systems  Division's  requirements.  A  number  of  specific 
relations  have  been  created  using  the  GDBMS  for  underwater  systems  studies. 

GDBMS  uses  a  relational  database  approach  whereby  relations  may  be 
manipulated  individually  (as  in  the  data  acquisition  or  modelling  and 
verification  stages)  or  'joined'  and  interfaced  to  user  programs  for 
advanced  systems  studies.  The  purpose  of  this  report  is  to  give  an 
overview  of  GDBMS  and  the  design  concepts,  method  of  operation  and  examples 
of  relations  running  under  GDBMS. 


2.  THE  ROLE  OF  THE  DATABASE 
2.1  Historical  development 

The  acquisition,  storage  and  management  of  large  amounts  of  data  always 
requires  effort  and  encounters  problems.  Until  recently  the  storage  medium 
was  usually  paper  and  when  the  volume  of  data  became  large  the  need  for 
searches  and  quick  access  became  difficult  to  satisfy.  With  the  advent  of 
mainframe  computers  of  significant  power  centralised  filing  systems  for 
large  quantities  of  data  (usually  of  an  accounting  or  inventory  nature) 
were  developed.  The  development  of  databases  followed,  with  bibliographic 
databases  finding  ready  acceptance  with  libraries  and  their  users.  The 


VSRL-TN-50/88 


advent  of  significant  computing  power  and  digital  storage  capacity  for 
relatively  low  cost  is  generating  increasing  interest  in  more  general 
purpose  databases . 

We  are  interested  in  using  mainly  numeric  data  of  environmental, 
oceanographic  or  geophysical  origin.  The  importance  of  efficient  retrieval 
of  this  data  is  obvious,  but  achieving  this  in  practice  is  becoming 
increasingly  difficult  using  traditional  methods.  Particularly  in  the 
oceanographic  sciences,  "it  is  infrequently  that  the  data  generator  (the 
measurer  or  reporter)  is  also  the  end  user  (the  one  who  applies  these  data 
in  calculations,  or  in  new  experimental  design. .. )"(ref. 1) .  This  is  a 
natural  consequence  of  the  scale  of  resources  needed  and  reflected  in  the 
growing  costs  to  perform  environmental  measurements  in  this  field.  The 
paucity  of  data,  and  the  difficulties  (or  often  impossibility)  of 
replicating  experiments  lead  to  concern  with  the  observation  that 
"especially  for  interdisciplinary  purposes,  data  can  be  considered  lost  if 
they  are  not  available  in  reliable,  retrievable  form"(ref . 1) . 

An  examination  of  the  way  in  which  this  data  is  normally  used,  revealed 
that  mere  access  to  data  only  solved  part  of  the  problem  -  experimental 
data  is  required  for  some  purpose,  usually  comparison  with  other  data  or  a 
model,  and  interpretation  as  to  its  physical  significance.  The  central 
role  of  the  interpretative  function  in  science  is  admirably  brought  out  in 
a  recent  survey  of  numeric  databases (ref . 1) . 

They(ref.l)  concluded  that  manipulation  of  numeric  data  is  fundamental  to 
the  methods  of  scientific  enquiry.  The  transfer  of  data  between 
experiments,  evaluation,  conclusions  and  dissemination  is  vital  to  the 
whole  process.  Despite  the  acknowledged  importance  of  the  development  of 
efficient  data  transfer  mechanisms,  "it  is  often  considered  the  least 
glamorous  part  of  our  total  scientific  research  program,  and  therefore 
nearly  always  displays  severe  symptoms  of  neglect"(ref . 1) .  It  was  clear 
during  the  early  stages  of  this  database  system,  that  to  fully  exploit  the 
capabilities  of  a  computerised  retrieval  system,  the  operating  system 
should  have  significant  additional  capabilities  compared  to  the  simple 
bibliographic  retrieval  systems  which  have  been  available  up  to  now.  In 
recognition  of  these  ideas,  it  became  one  of  the  aims  of  this  activity  to 
develop  a  computer-based  aid  which  would  significantly  increase  the 
productivity  of  scientists  and  engineers  working  on  research  and 
development  of  underwater  detection  systems. 

2.2  Features  required  in  a  working  scientific  database 

As  noted  in  discussions  below,  the  acceptance  of  pioneering  attempts  to 
computerise  the  task  of  retrieval  of  oceanographic  data,  has  been  varied, 
and  differences  in  effectiveness  suggest  that  the  method  of  implementation 
of  such  a  system  can  be  quite  important.  Factors  which  were  addressed  in 
the  development  of  the  present  system  are  listed  below,  and  are  discussed 
in  greater  detail  in  later  sections. 

2.2.1  Data  storage 

The  first  requirement  of  such  a  system  is  the  capacity  to  reliably  store 
the  data  required.  Related  topics  included  the  variety  of  data  formats 
and  the  amount  and  type  of  associated  data  used  to  identify  or  index 
each  element.  (An  element  here  may  be  multi-dimensional,  eg  the  full 
set  of  propagation  loss  readings  at  various  frequencies  and  ranges  at  a 
particular  site.)  Efficient  storage  of  data  without  data  loss  is  highly 
desirable. 
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2.2.2  Data  seatch 

In  a  workable  system  it  should  be  possible  to  automatically  locate  one 
or  a  set  of  elements  either  by  index,  or  by  selected  attributes  (eg  all 
data  south  of  a  certain  latitude  and  after  a  certain  date). 

2.2.3  Data  retrieval  and  presentation 

This  was  an  area  which  previously  caused  considerable  difficulty  in  the 
interpretive  data  assessment  task  when  using  paper  storage  media.  In 
practice,  data  were  often  measured  at  different  frequencies  and,  when 
recorded  graphically,  plotted  on  different  scales.  As  it  is  frequently 
desirable  to  present  complex  data  graphically  and  ready  for 
interpretation,  it  was  considered  that  a  'working  database1  should  be 
able  to  present  data  graphically,  and  overlay  data  from  any  source  on 
the  user  selected  output  format.  When  this  was  done  the  tasks  of 
immediate  user  interpretation  or  subsequent  processing  (ie  averaging  a 
subset  of  the  data)  would  be  possible.  A  related  problem  in  a 
multi-user  environment  is  to  be  able  to  present  data  on  different  output 
devices.  The  data  should  also  be  adequately  labelled  to  aid  the  user. 

2.2.4  Data  manipulation 

Here  the  intention  was  to  aid  interpretation  by  comparison,  accumulation 
of  statistics  to  obtain  macro-data,  and  other  arithmetic  'joining' 
operations,  eg  to  display  the  difference  between  model  predictions  and 
experimental  results.  For  studies,  it  is  also  desirable  to  be  able  to 
interpolate  between  values  of  the  independent  variables,  particularly 
for  model  outputs  where  behaviour  is  known. 

As  will  be  explained  later  the  process  of  scientific  model  building 
relies  on  successive  evaluation  of  the  data  and  model  predictions.  It 
was  considered  essential  that  model  predictions  should  be  able  to  be 
readily  inserted  in  the  database,  and  that  software  performing 
operations  (typically  either  on  verified  macro-data  or  model  outputs)  on 
the  data  should  be  able  to  access  the  database  at  run  time. 

2.2.5  Database  management 

This  heading  covers  a  range  of  features,  the  most  important  being  to 
allow  insertion,  correction  and  deletion  of  data  and  attributes,  the 
maintenance  of  data  with  integrity  (ensuring  that  subsequent  additions 
cannot  corrupt  previously  entered  data)  and  transfer  of  data  and 
attributes  to  other  programs  or  databases.  If  the  database  management 
structure  has  sufficient  flexibility  then  it  should  be  possible  to  use 
it  for  a  range  of  subjects  having  numeric  data  of  similar 
dimens ionality . 

With  data  from  a  range  of  sources  -  experimental,  models,  or  unknown 
original,  it  is  essential  that  the  validity  and/or  accuracy  of  the  data 
be  recorded  with  the  data  so  that  confidence  levels  in  its  use  can  be 
intimated  to  a  new  user  accessing  it.  This  requires  assessment  of  the 
data  by  a  knowledgeable  person  preferably  at  the  time  of  entry,  and  that 
some  sort  of  validity  flag  or  index  be  permanently  stored  with  the  data. 

2.2.6  User  friendliness 

The  establishment  of  a  DBMS  to  be  used  by  a  range  of  specialists  (but 
not  specialists  in  computer  science)  demands  that  it  be  'user  friendly'. 
This  is  a  reflection  of  the  historical  observation  "DBMS  documentation 
is  notorious  for  being  hard  to  follow,  and  practically  impossible  to 
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understand"(ref .2) .  In  effect  the  aim  is  to  ensure  that  a  novice  can 
operate  the  system  without  the  need  for  special  advice  or  the 
requirement  to  learn  a  complicated  new  language.  This  effect  is 
normally  achieved  by  the  use  of  a  'menu-driven'  software  or  a  simplified 
special  command  language.  Either  approach  can  work  without  recourse  to 
manuals  only  if  an  adequate  level  of  prompts  is  supplied  and  if 
on-screen  help  can  be  called  up  at  any  time. 

A  second  highly  desirable  simplification  for  non-programmer  users  is  to 
minimise  the  number  of  key-strokes  required  in  an  interactive  session. 
It  is  assumed  here  that  for  working  analysis,  the  user  needs  to  look  at 
and  operate  upon  the  elements  being  retrieved  from  the  database  in  real 
time,  and  not  with  delays  as  in  batch  mode.  As  any  flexible  system  will 
provide  a  wide  range  of  options  to  the  user,  this  implies  that  default 
options  are  desirable  for  standard  operations,  and  that  consideration  be 
given  to  storing  'user  profiles'  for  users  who  regularly  operate  in  non 
standard  modes. 

2.3  Existing  underwater  acoustics  databases  and  related  computer  models 

Databases  or  related  computer  packages  for  underwater  acoustics 
applications  exist  at  a  number  of  locations  outside  Australia(ref . 3,4 ,5 ,6) . 
Their  designs  and  configurations  depend  upon  the  expected  users,  who  could 
be  research  scientists  developing  models,  systems  designers  investigating 
new  concepts  or  military  personnel  wishing  to  predict  the  "detection  range 
for  today"  for  specific  targets  using  current  systems.  Consequently 
different  sets  of  options  need  to  be  provided  by  a  database  system  to  cover 
these  user  types.  They  can  be  classified  in  terms  of  the  following  three 
basic  variants:  Research,  Systems  Design  and  Application  Models. 

2.3.1  Research  models 

These  can  be  characterised  as  having  the  following  form: 

(1)  Many  options 

(2)  Results  of  intermediate  calculations  available  for  debugging 
and  checking 

(3)  Include  as  much  physics  as  possible 

(4)  Minimal  mathematical  approximation 

(5)  Complex  environmental  input  needed 

(6)  No  automatic  database  for  reference 

(7)  No  management  of  software 

(8)  Usually  require  a  mainframe  computer 

(9)  Execution  time  relatively  unimportant 

(10)  Specific  topics  have  specialised  algorithms 

(11)  Outputs  include  simple  graphics. 


5 


WSRL-TN-50/88 


2.3.2  Systems  design  models 

These  can  be  characterised  as  having  the  following  form: 

(1)  Many  options  but  usually  defaults  available 

(2)  Less  diagnostics  compared  to  the  research  model 

(3)  The  physics  is  simplified  to  various  models 

(4)  Minimal  mathematical  approximation 

(5)  Standard  environmental  inputs  used 

(6)  Part  access  to  database  for  input 

(7)  Software  managed  loosely 

(8)  Usually  require  a  mainframe  computer 

(9)  Execution  time  relatively  unimportant 

(10)  Basic  models  are  brought  together 

(11)  Graphics  used  extensively. 

2.3.3  Applications  models 

These  can  be  characterised  as  having  the  following  form: 

(1)  Limited  options  if  any 

(2)  No  diagnostics  (other  than  for  operator  guidance) 

(3)  Many  physical  assumptions 

(4)  Many  mathematical  approximations 

(5)  Environmental  inputs  for  position  and  data  from  database 

(6)  Use  measured  data  if  available 

(7)  Software  controlled 

(8)  Can  use  mainframe  or  desktop  computers 

(9)  Fast  execution  required  (possibly  at  the  expense  of  accuracy) 

(10)  Important  factors  may  be  combined  in  simple  forms 

(11)  Simple  clear  graphics  and  scalar  readouts  (eg,  range  of  the  day 
prediction) . 

During  studies  being  undertaken  at  WSRL  on  passive  sonar  array  systems, 
it  was  realised  that  the  outputs  of  various  research  models  would  need 
to  be  combined  with  environmental  data  (which  exists  or  will  be 
collected  in  the  future)  to  provide  a  systems  design  model.  However, 
limited  staff  and  resources  led  to  constraints  in  the  development  of 
this  model.  It  was  also  realised  that  the  WSRL  databases  and  their 
GDBMS  software  could  be  made  available  for  use  as  RAAF  and  RAN 
applications  models. 
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2.4  Overseas  approaches  to  the  problem 

Prior  to  and  during  the  development  of  underwater  acoustic  databases  at 
WSRL,  the  methods  adopted  at  Naval  Ocean  Research  and  Development  Activity 
(NORDA) (ref . 3 ,4) ,  Supreme  Allied  Command  Atlantic  Research  Center 
(SACLANTCENTER) (ref .5)  and  Naval  Underwater  Systems  Center  (NUSC)  were 
considered(ref .6) .  The  NORDA  and  Fleet  Numerical  Oceanography  Center 
(FNOC)  approach  requires  the  whole  ocean  environment  tc  be  mapped  with 
respect  to  all  the  relevant  parameters.  Using  these  data  the  system 
constantly  recalculates  propagation  loss  and  ambient  noise  to  obtain  signal 
excess  and  probability  of  detection.  This  method,  the  Automated  Signal 
Excess  Prediction  System  (ASEPS),  requires  extensive  databases,  computer 
execution  time  and  confidence  that  various  intermediate  calculations  give 
meaningful  outputs.  The  propagation  loss  input  to  ASEPS  is  calculated 
using  one  model.  This  approach  precludes  the  use  of  different  models  for 
different  frequency  ranges,  or  environments,  or  the  use  of  real  data  if 
available.  Similarly,  ambient  noise  is  calculated  and  one  cannuL  choose  to 
use  real  data. 

The  Generic  Sonar  Model(ref.6)  operates  in  a  similar  manner,  ie  continuous 
recalculation  on  a  mainframe  computer.  Its  strongest  feature  is  its 
ability  to  easily  use  various  propagation  models  with  the  same  input  data. 
Its  fundamental  weakness,  however,  is  its  limitation  to  ray  tracing  at  high 
frequency  in  deep  water  (ie  not  useable  at  low  frequency  in  shallow  water), 
poor  ambient  noise  description  and  lack  of  environmental  knowledge.  The 
systems  user  must  provide  all  the  appropriate  environmental  data  for  each 
calculation. 

2.5  WSRL  approach 

The  alternative  approach  developed  here  has  some  similarity  to  that  used  at 
SACLANTCENTER(ref .5) .  The  results  of  experiments  and  theoretical 
calculations  using  ray  tracing  (FACT9H,  RAVMODE82),  the  parabolic  equation 
method  (IFD  and  split  step),  normal  modes  (SNAP)  and  the  Fast  Field  Program 
(SAFARI)  are  stored  in  a  separate  database.  The  input  for  these 
calculations  can  also  be  stored  for  use  by  the  acoustician  but  are  not 
required  by  the  system  designer.  In  this  approach  both  experimental  and 
theoretical  data  can  be  used  in  the  prediction  of  system  performance, 
without  the  need  for  repeated  recalculation.  The  ambient  noise  calculation 
model  can  call  upon  the  propagation  loss  database  for  the  appropriate  data 
and  the  final  noise  results  can  also  be  stored  in  an  ambient  noise  database 
along  with  measured  data.  Because  the  measurements  are  stored,  the 
comparison  of  theory  with  experiment  is  much  more  efficient  because  the 
calculated  outputs  are  be  automatically  in  the  same  format.  Thus  the 
system  designer  accesses  data  with  the  acoustician's  "seal  of  approval".  A 
further  advantage  of  the  WSRL  method  is  that  whole  databases  can  readily  be 
transported  to  different  hardware,  eg  simulators  and 
micro-computers (ref . 7) .  Thus  the  results  of  extensive  and  sophisticated 
calculations  can  be  utilised  in  applications  models  for  the  RAAF  and  RAN. 

2.6  DBMS’s  in  general  -  commercial  DBMS 

Two  DBMS's  already  available  on  the  DSTO  Salisbury  central  computer  are  IMS 
and  SAS.  Some  brief  comments  about  their  suitability  to  our  applications 
follows.  IMS  was  one  of  the  first  large  DBMS  available.  IMS,  an  IBM 
product,  provides  a  flexible  but  complex  hierarchical  DBMS  primarily  for 
business  and  accounting  types  of  applications.  It  is  too  complex  for 
untrained  scientific  specialists,  especially  since  its  base  language  is 
COBOL.  These  comments  also  apply  to  the  other  CODASYL  DBMS's.  IMS  also 
has  questionable  efficiency  when  confronted  with  data  files  of  the  size 
that  would  be  required  for  say,  range  and  frequency  dependent  propagation 
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loss  data  (ie  3  dimensional)  at  hundreds  of  sites  and  with  a  multiplicity 
of  source  and  receiver  depth  combinations.  Indeed  the  lack  of  an  efficient 
means  of  representation  of  multidimensional  numerical  data  appeared  to  be  a 
fundamental  stumbling  block  for  all  conventional  DBMS's.  SAS  (Statistical 
Analysis  Systems)  came  closer  to  our  requirements  in  terms  of  its  numerical 
and  graphics  facilities,  but  its  data  management  abilities  are  only 
rudimentary  (although  they  could  be  programmed  using  SAS  as  a  core). 

On  the  other  hand,  relational  DBMS's  are  a  newer  development  compared  to 
hierarchical  systems  (such  as  IMS),  and  have  more  attractive  capabilities. 

However,  commercially  available  relational  DBMS's,  and  indeed  research 
systems,  still  did  not  possess  the  numerical  capabilities  required  by 
WSRL(ref . 11 ) . 


3.  THE  DEVELOPMENT  OF  GDBMS 

GDBMS  was  developed  by  one  of  the  authors  (Keays)  as  a  relational  DBMS  to 
fulfil  the  specific  needs  outlined  above.  Additionally,  the  following 
advantages  became  apparent  as  system  development  proceeded. 

(1)  GDBMS  is  general  purpose  DBMS  specially  suited  to  scientific  use. 
Without  the  special  numerical  capabilities  GDBMS  (as  defined  in 
reference  13)  is  a  fully  relational  DBMS  as  defined  in  reference  11  with 
all  the  theoretical  advantages  that  entails(ref . 12) .  The  addition  of  a 
multi-dimensional  numerical  attribute  domain,  while  lacking  theoretical 
integration  to  the  relational  model,  provides  a  facility  of  great  power  and 
wide  applicability. 

(2)  The  Pascal  code  for  GDBMS  is  concise  and  obviously  accessible.  This 
provides  the  advantage  over  commercial  systems  that  modifications  and 
enhancements  are  quickly  and  readily  implemented.  The  data  file  formats 
are  well  defined  and  are  necessarily  supported  by  new  software  versions. 
This  also  tends  to  maintain  a  stable  user  interface. 

(3)  The  different  requirements  of  Research  Systems  application  models  are 
well  met  by  GDBMS.  As  a  simple  but  powerful  interface  between  application 
software  and  the  database  it  allows  both  acoustic  modelling  and  operational 
systems  to  be  well  supported. 

(4)  The  use  of  GDBMS  obviates  much  redundant  software  development  by 
virtue  of  its  arithmetic,  graphics  and  data  retrieval  facilities  and  its 
comprehensive  external  interface.  Availability  of  the  source  code  is  also 
useful  in  this  respect. 

(5)  Software  development  based  on  GDBMS  is  cheaper  as  no  external 
licensing  is  required,  especially  for  multiple  installations  as  required 
for  operational  systems. 

(6)  Local  software  development  and  the  use  of  Pascal  made  porting  GDBMS  to 
the  IBM  PC  possible  (see  Section  3.5). 

3.1  Relational  databases 

A  relation  is  a  two  dimensional  table  of  entries,  with  columns  representing 
attributes  of  a  data  record  of  'tuple'  (ie  fields  of  a  record),  and 
extending  downwards  as  new  records  are  added  as  shown  schematically  in 
figure  1.  This  tabular  organisation  is  much  simpler  conceptually  than  the 
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hierarchical  database  (consisting  of  an  arbitrarily  complex  graph 
structure).  This  is  especially  important  for  non-programmers'  ability  to 
use  a  DBMS. 

Projection:  Selects  all  the  data  from  tuples  in  a  relation  (ie  particular 
database)  but  includes  only  the  data  in  specified  columns  (ie 
for  stipulated  attributes). 

Restriction:  Selects  a  subset  of  tuples  which  meet  specified  conditions  (eg 
if  selected  attribute  values  fall  within  specified  ranges). 

Join:  Combine  tuples  from  two  relations  to  form  a  third  relation 

whose  attributes  are  the  set  union  of  the  attributes  of  the 
original  relations,  with  the  restriction  that  the  tuples  are 
only  joined  if  specified  common  attributes  have  the  same 
values  in  the  original  tuples.  (See  reference  12  for  examples 
of  the  usefulness  of  this.) 

The  conceptual  simplicity  of  relational  databases  puts  more  onus  on  the 
DBMS  to  represent  and  manipulate  the  data  in  an  efficient  and  flexible  way. 
The  theory  of  relational  databases  is  well  developed  (but  still  an  active 
field  of  research(ref . 12) )  .  It  is  widely  accepted  that  relational 
databases  provide  many  advantages  over  hierarchial  and  network 
architectures  by  virtue  of  their  regular  algebra  and  other  theoretical 
considerations.  However  some  implementations  have  had  a  reputation  for 
inefficiency.  This  has  not  proven  to  be  a  problem  with  GDBMS. 

3.2  Attribute  types 

GDBMS  supports  attribute  types  based  on  Pascal  type  concepts. 

3.2.1  Character  strings 
These  are  common  to  all  DBMS's. 

3.2.2  Integers  and  real  numbers 

Most  DBMS  support  these  types.  GDBMS  implements  them  in  numeric  formats 
rather  than  BCD  or  ASCII,  for  efficiency. 

3.2.3  Enumerated 

Enumerated  types  (ie  a  finite  number  of  named  values)  are  a  powerful 
feature  of  Pascal.  Similarly  they  are  used  in  GDBMS  as  the  most  natural 
way  of  representing  many  attributes.  This  type  facilitates: 

(1)  Efficient  multi-key  hashing  algorithms 

(2)  Natural  queries  using  sets 

(3)  Efficient  storage. 

Enumerated  type  are  rarely  seen  in  commercial  DBMS's. 

3.2.4  Multi-dimensional 

The  multi -dimensional  type  is  the  key  to  the  power  of  GDBMS  in 
scientific  and  engineering  applications.  It  allows  the  storage  of 
n-dimensional  arrays  of  scalar  data  where  n  is  an  arbitrary 
dimensionality  (a  vector  function  could  be  represented  by  a  number  of 
such  attributes ) . 
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GDBMS  provides  graphical  facilities  for  input-  and  output  of  these  data 
but  they  are  not  at  present  used  for  database  searches. 

Figures  2  and  3  are  examples  of  graphical  output  of  GDBMS. 

3.3  Join 

Join  is  a  fundamental  and  powerful  operation  in  relational  DBMS's.  Its 
application  in  GDBMS  is  described  fully  in  reference  13.  Briefly,  it 
combines  2  or  more  relations  to  form  a  new  one  by  operating  on  a  kind  of 
cartesian  product  of  the  relations.  The  facility  is  extremely  useful  when 
evaluating  the  sonar  equation,  for  example,  where  each  term  in  the  equation 
is  obtained  from  an  appropriate  relation.  Deferring  to  the  next  section 
the  topic  of  arithmetic  operations  on  database  elements,  the  important 
thing  to  note  here  is  the  facility  of  the  join  operation  to  create  a  new 
attribute  list  for  the  new  signal  excess  relation  (for  example)  by 
computing  the  appropriate  union  of  attributes  from  the  joined  relations,  eg 
the  target  type  attribute  from  the  target  relation  and  the  sea  state 
attribute  ambient  noise  relation  both  appear  as  attributes  in  the  signal 
excess  relation  derived  from  them. 

3.4  Arithmetic  on  multi-dimensional  attributes 

Complementary  to  the  join  operation  is  the  ability  to  perform  arithmetic 
operations  on  multi-dimensional  attributes.  This  is  fully  defined  in 
reference  13  but  requires,  inter  alia,  interpolation  over  the  intersection 
of  the  domain  of  the  functions  represented  by  the  multi-dimensional 
attributes  in  the  terms  of  arithmetic  expression. 

In  essence  this  is  the  facility  to  perform  arithmetic  operations  (user 
specified  in  the  high  level  language  PASCAL)  on  one  or  more  data  values 
obtained  from  selected  tuples  in  nominated  relations.  To  avoid  problems 
caused  when  comparing  or  operating  on  parameters  sampled  at  different 
values  of  the  (same)  independent  variable(s),  automatic  linear 
interpolation  of  the  input  data  is  available  if  the  required  values  are 
spanned  in  the  source  tuples. 

This  facility  allows  the  user  to  graph,  eg  Signal  Excess  vs  range  vs 
frequency  by  summing  the  terms  stored  in  several  relations  or  to  compare 
two  graphs  of  propagation  loss  by  graphing  the  difference  of  two  tuples  in 
the  propagation  loss  relation. 

3.5  Mainframe  vs  PC 

GDBMS  was  originally  written  for  the  DSTO  IBM  370/3033  central  computer  but 
later  ported  to  the  IBM  PC  XT(ref.7).  Currently,  software  development  is 
done  on  the  PC  using  the  'Turbo  Pascal'  system.  Working  code  is  then 
transferred  to  the  mainframe. 

This  dual  implementation  offers  the  following  advantages. 

(1)  The  mainframe  database  may  be  accessed  by  anyone  on  the  network 
(which  has  terminals  at  DSTO  Salisbury  and  DSTO  Sydney). 

(2)  Small  databases  on  floppy  disks  may  be  carried  between  PC's. 

(3)  PC  databases  may  be  established  by  transferring  a  subset  of  one  or 
more  databases  from  the  mainframe  and  the  latter  may  be  augmented  by 
inputting  data  from  a  PC  database.  For  example,  the  mainframe  terminal 
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at  DSTO  Sydney  lacks  a  graph  digitiser  facility  but  a  digitiser  may  be 
purchased  for  a  PC,  the  data  entered  on  a  floppy  disk  database  and  then 
loaded  into  the  mainframe  database. 

(4)  PC's  will  provide  the  basis  for  operational  systems  using  either 
floppy  disks  or  portable  hard  disks. 

(5)  PC's  are  relatively  cheap  and  there  is  a  wide  variety  of  third 
party  peripherals  and  software  available. 

(6)  Software  development  by  contractor  is  more  competitive  on  the  PC. 


4.  RELATIONS  IN  THE  UNDERWATER  ACOUSTICS  DATABASE 

Tables  1  to  6  contain  listings  of  the  definition  files  for  relations  currently 
in  use.  They  are  self-explanatory. 


5.  INTERFACE  WITH  A  USER  PROGRAM  (PASP) 

PASP  is  an  acronym  for  Passive  Sonar  Prediction.  This  program ( re f . 10)  was 
developed  to  compute  predictions  for  the  likely  detection  range  to  be  expected 
from  generic  passive  sonar  systems.  Several  forms  of  output  are  available, 
including  signal  excess,  equivalent  detection  range  (for  systems  of  specific 
gain)  and  probability  of  detection  (assuming  ideal  or  experimental  transition 
curves) . 

The  only  specific  sonar  modelling  performed  within  this  software  is  concerned 
with  the  frequency  dependent  gain  and  detection  thresholds  for  specific  types 
of  arrays  and  processors.  In  execution  the  program  undertakes  the 
computationally  trivial  task  of  evaluating  the  Sonar  Equation.  The  usefulness 
of  this  program  stems  from  the  fact  that  in  each  run  it  evaluates  the  Sonar 
Equation  for  every  standard  frequency  and  range  pair  for  which  sufficient 
input  data  are  available.  The  output  data  are  thus  three-dimensional,  and  the 
user  has  a  choice  of  output  devices  and  formats.  The  flexibility  of  this 
software  is  due  in  large  part  to  the  fact  that  it  obtains  the  data  needed  for 
each  run  from  the  relevant  relations.  All  the  array  and  processor  independent 
data  are  accessed  from  the  relevant  relations.  At  the  present  time  there  are 
relations  for  Ambient  Noise,  Self  Noise,  and  Propagation  Loss.  The  program 
accesses  the  relations  at  run  time  and  for  efficiency  retrieves  the  entire 
requested  attribute  in  one  pass.  In  the  case  of  propagation  loss  one 
attribute  is  a  sequence  of  vectors  describing  propagation  loss  data  at 
different  frequencies.  The  actual  frequencies  found  are  not  critical  as, 
provided  the  desired  run  frequency  being  evaluated  at  any  instant  is  within 
the  span  of  the  data  from  the  database,  the  interface  software  will 
interpolate  to  the  required  frequency.  The  data  are  mapped  similarly  onto  the 
range  scale. 

For  convenience,  the  program  is  menu-driven,  and  displays  results  to  the 
operator  interactively.  To  reduce  complexity  to  an  acceptable  level,  the  user 
must  know  the  identity  (address)  of  the  records  or  'tuple's'  to  be  called  in 
each  relation  before  running  the  program.  The  relevant  addresses  are  entered 
into  the  menu  before  program  execution.  This  is  not  considered  a  handicap, 
because  in  practice  significant  effort  is  always  required  in  selecting, 
processing  and  validating  data  (the  tasks  which  GDBMS  was  designed  to 
facilitate)  prior  to  using  it  as  input  to  systems  studies. 

More  detailed  information  on  how  to  use  the  PASP  program  is  available 
elsewhere(ref . 10) . 
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6.  ADMINISTRATION  AND  VERIFICATION  PROCEDURES 

For  a  complex  software  system  such  as  GDBMS  and  its  individual  databases  it  is 
essential  that  control  over  the  input  data  and  any  software  modifications  are 
maintained.  Consequently  there  are  a  number  of  documents  that  need  to  be 
available.  These  include: 

(1)  Functional  description 

(2)  Program  specification 

(3)  User's  manual 

(4)  Data  Validation  -  a  set  of  administrative  procedures  and  instructions 
to  permit  control  over  this  data  flow  into,  within  and  out  of,  the 
database . 

Items  2  and  3  are  being  provided  as  part  of  the  software  development 
contract (ref . 13) . 


7.  DATA  EXCHANGE 

GDBMS  provides  the  formats  for  data  exchange  either  physically  on  magnetic 
media,  or  electronically. 

7.1  Within  Australia 

Database  exchange  between  elements  of  Maritime  Systems  Division  and  other 
DSTO  Laboratories  should  become  routine  as  the  database  grows. 

Operational  systems  would  rely  on  distribution  of  data  from  Australian 
Defence  Force  authorities,  which  have  responsibility  for  collecting  and 
analysing  data,  to  the  operational  systems  on  ships  or  aircraft.  Data 
transfer  should  also  occur  between  Maritime  Systems  Division  and  these 
authorities . 

7.2  International  exchange 

It  is  hoped  that  GDBMS  will  be  made  widely  available,  thus  providing  a 
medium  of  scientific  data  exchange  internationally. 


8 .  SUMMARY 

This  document  describes  the  philosophy  behind  the  development  of  GDBMS  in 
WSRL.  It  identifies  the  functions  required  of  a  scientific  database  to  handle 
oceanographic  (or  similar)  data  for  both  ocean  acoustic,  and  systems  studies 
modelling.  Available  commercial  systems  were  found  to  have  significant 
shortcomings.  The  functions  of  the  new  software,  implemented  in  Maritime 
Systems  Division  to  meet  these  requirements,  are  described.  The  advantages  of 
the  new  software  include  efficiency,  versatility,  portability  and  its  ability 
to  handle,  interpolate  from  and  display  multi-dimensional  arrays  of  numerical 
data.  The  software  is  designed  for  use  by  scientists  and  other 
non-specialists  in  computing. 


WSRL-TN-50/88 


12 


TABLE  1.  ATTRIBUTE  DEFINITIONS  FOR  THE  PROPLOSS  DATABASE 


VARIABLE  NAME 

PASCAL  TYPE 

PERMITTED  VALUES 

' Experimental ' 

ENUMERATED 

expermnt  theory 

'Low  f  b  loss' 

ENUMERATED 

A  B 

'High  f  b  loss' 
'XBT  Region' 

ENUMERATED 

low  med  high 

ENUMERATED 

TA  TB  TC  TD  TF  AB  AC  AD  AE  AF  AG  JB  BW  KI 
HW1  HW2  HW3  HW4  GH  GB  BA  TORRES  TIMORC 

OR1  GA  GC  GD  GF  GG  GJ  GE 

'P  L  Region' 

ENUMERATED 

North  South 

'Reliability' 

ENUMERATED 

unverif  low  med  high 

'Month' 

ENUMERATED 

Jan  Feb  March  April  May  June  July  Aug  Sep 
Oct  Nov  Dec 

'Year' 

INTEGER 

1900  2050 

'Comments ' 

CHARACTER  48 

' Latitude ' 

REAL 

-90  90  'Degrees' 

-180  180  'Degrees' 

0  6000  'Metres' 

' Longitude ' 

REAL 

'Water  Depth' 

REAL 

'Source  Depth' 
'Rec  Depth' 

'Prop  Loss' 

REAL 

0  6000  'Metres' 

REAL 

0  6000  'Metres' 

POINTER 

'Frequency'  'Hz' 

'Range'  'km' 

'Propagation  Loss'  'dB  @  lm' 

TABLE  2.  ATTRIBUTE  DEFINITIONS  FOR  THE  AMBNOIS  DATABASE 


VARIABLE  NAME 

PASCAL  TYPE 

PERMITTED  VALUES 

'Ship  or  Wind' 
'XBT  Region' 

ENUMERATED 

Ship  Wind  Both 

ENUMERATED 

TA  TB  TC  TD  TF  AB  AC  AD  AE  AF  AG  JB  BW  KI 
HW1  HW2  HW3  HW4  GH  GB  BA  TORRES  TIMORC 

0R1  GA  GC  GD  GF  GG  GJ  GE 

'P  L  Region' 

ENUMERATED 

North  South 

'Reliability' 

ENUMERATED 

unverif  low  med  high 

r Month ' 

ENUMERATED 

Jan  Feb  March  April  May  June  July  Aug  Sep 
Oct  Nov  Dec 

'Comments ' 

CHARACTER  48 

'Ship  Type' 

'Ship  Density' 
'Year' 

ENUMERATED 

Fish  Merchant  Naval  Other 

ENUMERATED 

Light  L/Med  Medium  M/Heavy  Heavy 

INTEGER 

1900  2050 

'Seastate' 

INTEGER 

0  9 

'Wind  Speed' 
'Latitude' 

REAL 

0  100  'Knots' 

REAL 

-90  90  'Degrees' 

-180  180  'Degrees' 

'Longitude' 
'Water  Depth' 

REAL 

REAL 

0  6000  'Metres' 

'Duct  Depth' 

'Rec  Depth' 

REAL 

0  6000  'Metres' 

REAL 

0  6000  'Metres' 

'Ambient  Noise' 

POINTER 

'Frequency'  'Hz’ 

'Noise'  'dB'  re  luPa**/Hz 

'Expt/Theory' 

ENUMERATED 

Expermnt  Theory 
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TABLE  3.  ATTRIBUTE  DEFINITIONS  FOR  THE  SELFNOISE  DATABASE 


VARIABLE  NAME 

PASCAL  TYPE 

PERMITTED  VALUES 

'Expermental ' 

ENUMERATED 

expermnt  theory 

'Country  origin1 

ENUMERATED 

AUST  US  UK  CAN  NZ  OTHER 

'Wall  material1 

ENUMERATED 

Rubber  PVC  PVC009  PVCH25  Other 

' Tow  mode ' 

ENUMERATED 

Surface  Subsurf  Barossa  Other 

'Type  of  fill' 

ENUMERATED 

Solid  Liquid  B-fibre  Other 

1  Comments ’ 

CHARACTER  48 

’No  hyds/grp1 

INTEGER 

0  50 

'Hose  diameter' 

REAL 

0  200  'mm' 

'Fill  density' 

REAL 

0  2000  ' kgm/m3 ' 

0  5000  'Metres’ 

'Array  length' 

REAL 

'Water  temper' 
'Group  length' 

REAL 

-50  50  'Celcius' 

REAL 

0  50  'Metres' 

'Dist  from  end' 

REAL 

0  5000  'Metres' 

'Self  Noise' 

POINTER 

'Speed'  'Knots' 

'Frequency'  'Hz' 

'Self  noise'  'dB  re  lmPa**2/Hz' 

TABLE  4.  ATTRIBUTE  DEFINITIONS  FOR  THE  VERTNOIS  DATABASE 


VARIABLE  NAME 

PASCAL  TYPE 

PERMITTED  VALUES 

'Ship  or  Wind' 

ENUMERATED 

Ship  Wind  Both 

'XBT  Region' 

'P  L  Region' 

ENUMERATED 

TA  TB  TC  TD  TF  AB  AC  AD  AE  AF  AG  JB  BW  KI 

ENUMERATED 

North  South 

'Reliability' 

'Month' 

' Comments ' 

ENUMERATED 

unverif  low  med  high 

ENUMERATED 

CHARACTER  48 

Jan  Feb  March  April  May  June  July  Aug  Sep 
Oct  Nov  Dec 

'Ship  Type' 

ENUMERATED 

Fish  Merchant  Naval  Other 

'Ship  Density' 

ENUMERATED 

Light  L/Med  Medium  M/Heavy  Heavy 

'Theory  or  Expt' 
'Year' 

ENUMERATED 

Theory  Experiment 

INTEGER 

1900  2050 

'Seastate' 

INTEGER 

0  9 

'Wind  Speed’ 

’ Lat itude ' 

REAL 

0  100  'Knots’ 

REAL 

-90  90  'Degrees' 

-180  180  'Degrees' 

0  6000  'Metres' 

'Longitude' 

REAL 

'Water  Depth' 
'Duct  Depth' 

REAL 

REAL 

0  6000  'Metres' 

'Rec  Depth' 

REAL 

0  6000  'Metres' 

'Vertical  Noise' 

POINTER 

'Frequency'  'Hz' 

'Elevation'  'Degrees' 

'Vertical  Noise'  'dB'  re  luPalV,'2/Hz 
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TABLE  5.  ATTRIBUTE  DEFINITIONS  FOR  THE  SOUNDVP  (SOUND  VELOCITY  PROFILE) 
DATABASE 


VARIABLE  NAME 

PASCAL  TYPE 

PERMITTED  VALUES 

' Expt /Theory ' 

' XBT  Region' 

ENUMERATED 

expermnt  theory 

ENUMERATED 

TA  TB  TC  TD  TF  AB  AC  AD  AE  AF  AG  JB  BW  KI 
HW1  HW2  HW3  KW4  GH  GB  BA  TORRES  TIMORC 

OR1  GA  GC  GD  GF  GG  GJ  GE 

'Comments ' 

'Reliability' 

'Month' 

CHARACTER  48 
ENUMERATED 

unverif  low  med  high 

ENUMERATED 

Jan  Feb  March  April  May  June  July  Aug  Sep 
Oct  Nov  Dec 

’Year’ 

INTEGER 

1900  2050 

' Lat itude ' 

REAL 

-90  90  'Degrees' 

-180  180  'Degrees' 

'Longitude' 

REAL 

'Water  Depth' 

' Sound  Speed ' 

REAL 

0  6000  'Metres' 

POINTER 

'Depth'  'Metres' 

'Sound  Speed'  'm/s' 

TABLE  6.  ATTRIBUTE  DEFINITIONS  FOR  THE  BLUG  DATABASE 


VARIABLE  NAME 

PASCAL  TYPE 

PERMITTED  VALUES 

'Reliability' 
'Comments ' 

ENUMERATED 
CHARACTER  48 

unverif  low  med  high 

'Region' 

ENUMERATED 

TA  TC  GH  BB  AB  AF 

' Province ' 

ENUMERATED 

Abyss  ip  Abyssih  Contrise  Contterr  Fan 

'Theory  or  Expt' 

ENUMERATED 

Theory  Experiment 

'Year' 

INTEGER 

1900  2050 

'Latitude' 

REAL 

-90  90  'Degrees' 

-180  180  'Degrees' 

0  6000  'Metres' 

' Longitude ' 

REAL 

'Water  Depth' 
'Bottom  Loss' 

REAL 

POINTER 

'Frequency'  'Hz' 

'Grazing  angle’  'Degrees' 

'Propagation  Loss'  'dB' 
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Figure  1.  Schematic  of  a  relation 


Example  of  data  in  one  tuple  in  the  GDBMS  Propagation  Loss  Relation 
displayed  using  the  line  graph  option 
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Figure  3.  Example  of  data  displayed  with  the  three-dimensional  colour 
plotting  option  in  GDBMS 


WSRL-TN-50/88 


DISTRIBUTION 


Number  of  copies 


Defence  Science  and  Technology  Organisation 
Chief  Defence  Scientist 

First  Assistant  Secretary  Science  Policy 

First  Assistant  Secretary  Science  Corporate  Management 

Director  General  Science  and  Technology  Programs 

Counsellor  Defence  Science,  London 

Counsellor.  Defence  Science,  Washington 

Weapons  Systems  Research  Laboratory 

Director,  Weapons  Systems  Research  Laboratory 

Chief,  Combat  Systems  Division 

Head,  Operations  Research  Group 

Chief,  Guided  Weapons  Division 

Chief,  Ordnance  Systems  Division 

Chief,  Maritime  Systems  Division 

Head  of  Composite,  Marine  Studies 

Head,  Underwater  Detection  Group 

Head,  Signal  Processing  and  Classification  Group 

Head,  Sea  Experiments  Group 

Head,  Ocean  Sciences  Group 

Head,  Sonar  and  Surveillance  Group 

Head,  Sonar  Engineering  Group 

Head  Underwater  Systems  Engineering  Group 

Head,  Mechanical  and  Fluid  Systems  Group 

Dr  A.S.  Burgess,  Underwater  Detection  Group 

Dr  D.J.  Kewley,  Underwater  Detection  Group 

Dr  G.B.  Gillman,  Underwater  Detection  Group 

Mr  A.C.  Temby,  Underwater  Detection  Group 

Dr  A.D.  Jones,  Underwater  Detection  Group 


1 


Cnt  Sht  Only 
Cnt  Sht  Only 


1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 


1 


WSRL-TN-50/88 


Dr  D.A.  Gray,  Signal  Processing  and  Classification  Group  1 

Dr  R.F.  Barrett,  Signal  Processing  and  Classification  Group  1 
Dr  M.W.  Lawrence,  Ocean  Sciences  Group  1 

Aeronautical  Research  Laboratory 

Director,  Aeronautical  Research  Laboratory  1 

Electronics  Research  Laboratory 

Director,  Electronics  Research  Laboratory  1 

Materials  Research  Laboratory 

Director,  Materials  Research  Laboratory  1 

Surveillance  Research  Laboratory 

Director,  Surveillance  Research  Laboratory  1 

Libraries  and  Information  Services 

Librarian,  Technical  Reports  Centre,  Defence  Central 
Library,  Campbell  Park  1 

Document  Exchange  Centre 
Defence  Information  Services  Branch  for: 

Microfiche  copying  1 

United  Kingdom,  Defence  Research  Information  Centre  2 

United  States,  Defense  Technical  Information  Center  12 

Canada,  Director  Scientific  Information  Services  1 

New  Zealand,  Ministry  of  Defence  1 

National  Library  of  Australia  1 

Main  Library,  Defence  Science  and  Technology 
Organisation  Salisbury  2 

Library,  Materials  Research  Laboratory  1 

Library,  Maritime  Systems  Division,  Sydney  1 

Librarian,  DSD,  Melbourne  1 

Australian  Defence  Force  Academy  Library  1 

Department  of  Defence 

Director  of  Departmental  Publications  1 

Joint  Intelligence  Organisation  (DSTI)  1 


WSRL-TN-50/88 


Navy  Office 

Navy  Scientific  Adviser  1 

Director  of  Submarine  Warfare  1 

AJAAC  1 

Project  Director,  New  Construction  Submarine  1 

Director,  Underwater  Warfare  1 

Project  Director,  ASTASS  1 

Air  Office 

Air  Force  Scientific  Adviser  1 

DORB  1 

Director,  LRMP  1 

Commanding  Officer,  92  Wing  Edinburgh  5 

ORMAR  1 

UNITED  KINGDOM 

Royal  Aerospace  Establishment,  Farnborough 

Library  1 

(Attention:  Dr  M.  Buckingham)  1 

Admiralty  Research  Establishment,  Portland 

Library  1 

(Attention:  Mr  G.  Kirby)  1 

UNITED  STATES  OF  AMERICA 

Naval  Ocean  Research  and  Development  Activity 

NSTL  Station,  Mississippi 

(Attention:  Technical  Director)  1 

(Attention:  Dr  R.A.  Wagstaff)  1 

(Attention:  Dr  R.  McGirr)  1 

Naval  Research  Laboratory,  Washington  DC 

Head,  Acoustics  Division  1 

(Attention:  Dr  W.A.  Kuperman)  1 

Naval  Underwater  Systems  Center,  New  London  CT 

Library  1 

(Attention:  Mr  D.G.  Browning)  1 

(Attention:  Mr  P.  Herstein)  1 

(Attention:  Mr  R.  Christian)  1 

(Attention:  Dr  R.  Kennedy  -  AUTEC)  1 


WSRL-TN-50/88 


Naval  Ocean  Systems  Center,  San  Diego  CA 

Library  1 

(Attention:  Dr  H.  Schenk)  1 

(Attention:  Dr  H.  Bucker)  1 

(Attention:  Dr  J.  Lovett)  1 

Marine  Physics  Laboratory,  Scripps  Inst  of  Oceanography, 

La  Jolla  CA 

(Attention:  Dr  F.  Fisher)  1 

CANADA 

Defence  Research  Establishment,  Atlantic,  Dartmouth  NS 

Library  1 

(Attention:  Dr  D.  Ellis)  1 

(Attention:  Dr  J.  Stockhausen)  1 

Defence  Research  Establishment,  Pacific,  Victoria  BC 

Library  1 

(Attention:  Dr  R.  Chapman)  1 

(Attention:  Dr  P.  Zakarauskas)  1 

NEW  ZEALAND 

Defence  Scientific  Establishment,  Auckland 

Library  1 

(Attention:  Dr  R.W.  Bannister)  3 

Spares  3 


Total  number  of  copies 


104 


DOCUMENT  CONTROL  DATA  SHEET 


Security  classification  of  this  page:  j  UNCLASSIFIED 


1  DOCUMENT  NUMBERS 


AR 

] 

j 

Number : 

AR-005-44 1 

Series 

Number : 

WSRL-TN-50/88 

Other 

Numbers : 

; 

1 

2  SECURITY  CLASSIFICATION 


a.  Complete 
Document : 

Unclassified 

b.  Title  in 

Isolation : 

Unclassified 

c.  Summary  in 

Isolation : 

Unclassified 

3  I  DOWNGRADING  /  DELIMITING  INSTRUCTIONS 


4  TITLE 

AN  INTEGRATED  DATABASE  ARCHITECTURE  FOR  SYSTEMS  STUDIES  IN  UNDERWATER 
ACOUSTICS 


l 


5  rPiRSONAL  AUTHOR  (S) 

D.J.  Kewley, 

P.S.  Keays  and 
A.S.  Burgess 


6  |  DOCUMENT  DATE 

[  October  1988 


7  1  7. 1  TOTAL  NUMBER 

OF  PAGES 

19 

7.  2  NUMBER  OF 

REFERENCES 

13 

8  8. 1  CORPORATE  AUTHOR  (S) _ 

Weapons  Systems  Research  Laboratory 


8.2  DOCUMENT  SERIES 
and  NUMBER 

Technical  Note 
50/88 


9  ]  REFERENCE  NUMBERS 


a. Task:  AIR  86/125 

b.  Sponsoring  Agency :  RAAF 

10  j  COST  CODE 

326/61341 7 


11  j  IMPRINT  (Publishing  organisation) _ 

Defence  Science  and  Technology 
Organisation 

J 


12j  COMPUTER  PROGRAM  (S) 
(Title  (s)  and  language  (s» 


13  RELEASE  LIMITATIONS  (d  the  document) 
Approved  for  Public  Release 


Security  classification  of  thic  page :  i  UNCLASSIFIED 


Security  classification  of  this  page  : 


UNCLASSIFIED 


14  ANNOUNCEMENT  LIMITATIONS  (of  the  information  on  these  pages) 
No  limitation 


I 


IS  DESCRIPTORS 

a.  EJC  Thesaurus 
Terms 


Data  base  management  systems 
Underwater  acoustics 
Oceanographic  data  processing 


b.  Non  -  Thesaurus 
Terms 


16  i  COSATI  CODES 


0062B 

0046A 

0047F 


17  SUMMARY  OR  ABSTRACT 

(if  this  is  security  classified,  the  announcement  of  this  report  will  be  similarly  classified) 


An  overview  of  the  development  of  an  Underwater  Acoustics  Database  for  use  in 
systems  studies  applications  is  given.  The  database  is  managed  by  the 
locally  developed  Graphical  Database  Management  System  (GDBMS) .  This  general 
purpose  database  management  system  has  been  designed  to  meet  the  needs  of 
scientists  working  with  oceanographic  data.  The  important  features  of  the 
system  include  the  flexibility  to  handle  data  in  a  variety  of  formats, 
minimum  redundancy  storage  space,  automatic  scaling  and  presentation  of  data 
from  dissimilar  sources  (in  user  specified  formats)  upon  retrieval,  and  the 
simple  keyword  driven  operation  designed  for  non-programmer  users.  Unusual 
features  include  the  provision  for  graphical  input  and  output  of 
multi-dimensional  data  and  interfaces  to  other  user  computer  programs. 
Examples  of  several  data  tables  or  'relations'  using  the  GDBMS  methods  are 
given.  Reference  to  how  the  database  can  be  accessed  by  the  Passive  Array 
Sonar  Prediction  (PASP)  code  which  provides  signal  excess  predictions  is 
also  included.  r 


Security  classification  of  this  page :  i  UNCLASSIFIED 


